home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2509 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 1 Feb 1996 11:49:39 +0100
  6. Organization: dis-
  7. Message-ID: <4eq5s3$mnn@serpens.rhein.de>
  8. References: <john.hendrikx.47u5@grafix.xs4all.nl>     <PETERM.96Jan29164036@tui.maths.irl.cri.nz>     <4ek6bo$84n@xmission.xmission.com> <4ekl5d$51@serpens.rhein.de>     <PETERM.96Feb1123338@tui.maths.irl.cri.nz>     <4ep546$hpr@serpens.rhein.de> <PETERM.96Feb1205215@tui.maths.irl.cri.nz>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. peterm@maths.grace.cri.nz (Peter McGavin) writes:
  12.  
  13. >mlelstv@serpens.rhein.de (Michael van Elst) writes:
  14. >>peterm@maths.grace.cri.nz (Peter McGavin) writes:
  15. >>>Current high-level gfx calls have a queue limit of 1 (or less than 1).
  16. >>
  17. >>Right. But that's as good as N.
  18.  
  19. >I assume you mean by creating another task to process the queue.
  20.  
  21. No, I mean for the interface. A caller now cannot rely on the operation
  22. being completed which means that you could extend the queue to any
  23. depth.
  24.  
  25. >There is a problem with the current implementation that WaitBlit() is
  26. >CPU-intensive for large blits.
  27.  
  28. Yes.
  29.  
  30. >So queuing large gfx operations
  31. >(perhaps with some smaller operations in the queue as well) eats CPU
  32. >time.
  33.  
  34. No, because you usually do not need to call WaitBlit() explicitely.
  35. The graphics functions do. And if these were using a real queue they
  36. could Wait() for a signal from the queuer.
  37.  
  38. >Maybe this can be fixed in the next implementation.  (I'm
  39. >talking about high-level gfx calls, not QBlit().)
  40.  
  41. Yes. Me too.
  42.  
  43. >Also, there may be problems queuing some operations like
  44. >ChangeScreenBuffer() when the Screen is opened by the parent task (or
  45. >perhaps not --- I don't really know).
  46.  
  47. This function would need to take care of queued operations. Right.
  48.  
  49. >>All you need is a proper model for synchronization. This should be
  50. >>done on either a bitmap or a rastport basis. Graphic operation can then
  51. >>be completely asynchronous as the driver decides.
  52.  
  53. >Sorry, I don't follow exactly what you're proposing here.
  54.  
  55. If you queue an operation and rely on the results you have to synchronize with
  56. the rendering. Just waiting "for the blitter" works if the blitter is the only
  57. hardware that you could wait for. For other hardware a WaitBlit() would have
  58. to synchronize with that hardware. And that is a big waste and WaitBlit()
  59. becomes slow too. What I propose is a WaitBitMap() that stops your task until
  60. all rendering done to that bitmap had been completed. After all you are not
  61. interested into other BitMaps when you want to examine the result (or free
  62. the BitMap). You would also need a lower-level function that gives you a
  63. message port or signal bit so that you can Wait() for it concurrently with
  64. other events.
  65.  
  66. Regards,
  67. -- 
  68.                                 Michael van Elst
  69.  
  70. Internet: mlelstv@serpens.rhein.de
  71.                                 "A potential Snark may lurk in every tree."
  72.